home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19990422-19990725
/
000133_news@watsun.cc.columbia.edu _Wed Jun 9 12:55:21 1999.msg
< prev
next >
Wrap
Internet Message Format
|
1999-07-23
|
5KB
Return-Path: <news@watsun.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA29046
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 9 Jun 1999 12:55:20 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id MAA22835
for kermit.misc@watsun.cc.columbia.edu; Wed, 9 Jun 1999 12:52:54 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: peter@baileynm.com (Peter da Silva)
Subject: Re: ISO VT320 emulator with key-bindings for Oracle Forms
Date: 9 Jun 1999 10:42:49 GMT
Organization: Bailey Network Management
Message-ID: <7jlgf9$8i8@web.nmti.com>
To: kermit.misc@watsun.cc.columbia.edu
In article <7jjshc$ere$1@newsmaster.cc.columbia.edu>,
Frank da Cruz <fdc@watsun.cc.columbia.edu> wrote:
>Yes, we know this, but the situation is far, FAR more complex than that. Try
>writing a communication program for UNIX that is:
>
> a. Portable to many UNIX varieties;
> b. Portable to assorted communication methods;
This can be handled by writing it as a wrapper around cu, kermit, tip,
or whatever. That way it'll even work for dumb programs that don't use
termcap.
> c. Works on the console, in remote sessions, and in xterm windows.
The latter case is not difficult. I wrote a termcap library back in '82,
and a vt100 and televideo emulator a few years later. If the system's
termcap is broken, you can fall back to that one, and at least one of the
freeware "vi" clones uses my termcap for that very purpose.
> a. Buggy;
> b. Inconsistent among different UNIX platforms and versions (e.g. the
> APIs differ -- even a simple function like tputs() has practically
> infinite combinations of return type and argument types, thus preventing
> any program that uses it from being portable without including hundreds
> of #ifdefs);
I haven't run into this problem, and I've written and ported an awful lot of
curses-based code between UNIX systems. Some code did a good job of
encapsulating the slight differences between implemetations of the termlib
API, and other code made no attempt to hide system dependencies and just
scattered ifdefs all over the place. Even otherwise well-written code like
early versions of Kermit had that problem.
> c. Dependent on buggy and/or incomplete databases;
That's something the end-user can fix.
> d. Offer only an incomplete and sketchy model of any real terminal,
> not even close to sufficient for defining an accurate emulation;
My vt100 emulator, which used raw termlib, did a better job of vt100
emulation than most commercial packages. It didn't try and provide
perfect visuals: double-wide and double-high letters, for example, were
simply not addressed. But it passed the vt100 torture test.
> e. Notorious for refusing to work due to library version mismatches;
> f. Sometimes not available at all.
That's an easy fix. Same solution as B.
>And that in any case, this does not solve the original problem:
>
> How do I map Shift-Alt-F7 to such-and-such a function?
>
>The answer will still be: "you can't, because the software has no way of
>knowing that you pressed Shift-Alt-F7".
With a keyboard mapping file that maps escape sequences to symbols that
the user's interested in.
>Furthermore, even when we give up on discovering what key the user actually
>pressed and follow the termcap/terminfo escape-sequence model, we still have
>the age-old problem of distinguishing the case where the user types the Esc
>key and then some other keys (as s/he might do when using EMACS) from the case
>where an escape sequence is generated by curses.
Oh yes, that's definitely a problem, but there's nothing any terminal emulator
can resolve, UNIX-based or not, because once it's mapped "UP" into "ESC O A"
or "ESC [ A" the bits on the wire are the same.
>If it was easy (or even possible) to write terminal emulators for UNIX, we'd
>have as many of them already floating around as we do for DOS and Windows.
Well, most modern UNIX systems come with an X-based VT100 emulator and there's
an X-based 3270 emulator from the same source available. There's not much
demand for curses-based emulators, because almost all UNIX software uses
termlib... the last time I had to configure a UNIX program for a terminal
was for the text editor in Intel's PL/M development kit back around 1984.
But there's at least a dozen commercial terminal emulators for UNIX... back
when I wrote my own (so we could run VMS software on our mix of Televideo
and Unisys tubes) I must have looked at six or eight of them just for
Xenix-286 (which was admittedly the #1 selling UNIX at the time). None of
them allowed you to wrap an arbitrary program, alas, and that was a hard
requirement.
Since then xterm and x3270 have become what Eric Raymond calls "category
killers". There's little demand for third-party free software alternates,
though that didn't stop rxvt from showing up. And I still get ads in the
mail for things like FacetTerm.
--
In hoc signo hack, Peter da Silva <peter@baileynm.com>
`-_-' Ar rug t� barr�g ar do mhact�re inniu?
'U` "Be vewy vewy quiet...I'm hunting Jedi." -- Darth Fudd